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(54) Vehicle sharing system and method with parking state detection 



(57) A shared vehicle system includes a central fa- 
cility 12, at least one vehicle distribution port facility 14 
and a plurality or fleet of vehicles 16. each having a ve- 
hicle subsystem 1 8. In general, the central facility 1 2 and 
port facility 14 and the vehicle subsystems 18 commu- 
nicate in a manner to allow a user to enter information 
at a port facility 14. That information is then communi- 
cated to the central facility 12, where the information is 
processed to select a vehicle 1 6 from the fleet to alkx:ate 
to the user 20 at the port facility 1 4, Selection of a vehicle 
1 6 for allocation to a user 20 nnay be based on selecting 
an available or soon to be available vehicle. according 



to various algorithnns that take into account the vehicles 
state of charge. The central station 12 also communi- 
cates with the port facility 1 4 and the vehicle subsystem 
18 to notify the user 20 of the selected vehicle 16, to 
provide secure user access to the selected vehicle 1 6, 
to monitor the location and operating status of vehicles 
in the fleet, to monitor the state of charge of electric ve- 
hicles and to provide other functions. The vehicles com- 
municate with the central statk)n to notify the central sta- 
tion of the PIN number of the individual 20 attempting to 
use the vehicle, and of vehicle parameters such as state 
of charge and location of the vehicle 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention : s 

[0CX)1] The present invention relates, generally, to 
systems and methods for sharing a fleet of vehicles 
among a plurality of users and, In preferred embodi- 
ments, to such systems and methods for sharing a fleet io 
of electric vehicles, including systems and methods re- 
lating to allocating, tracking, securing, managing and re- 
locating of shared vehicles and, in yet further preferred 
embodiments, to systems and methods relating to allo- 
cating, tracking, securing, managing, : relocating and '5 
charging of shared electric vehicles. 

Description of the Related Art : 

[0CX>2] In most modem, industrial countries, private 20 
automobiles play an important and sometimes indispen- 
sable rote as a means for transporting people within and 
beyond kx^al areas; for example, to and from places of 
work, study or worship, on errand trips or in commercial 
activities, such as deliveries, sales visits, repair visits or 2S 
the like. As a result of these Important roles, the number 
of automobiles in and arour>d most Industrialized cities 
and neighboring regions continues to grow. The increas- 
ing numbers of automobiles results In higher occurrenc- 
es of traffic jams and higher demands tor parking spac- 30 
es. 

[0003] Mass transit systems, such as busses, com- 
muter trains, subways, streetcars or the like can fulfill 
some of the trEinsportatkxi needs of those communities 
and municipalities that have such systems. However, 3S 
travel with such systems Is confined to pre-set stop lo- 
cations and times, set by the route and time schedule 
of the bus, train, subway or streetcar The prescribed 
routes and time schedules typically do not meet many 
travelers' needs or are too inconvenient for practical us- 40 
age of the nnass transportatbn system by some travel- 
ers. For many nriass transportatk)n users, the pre-set 
stop location is far enough from their origination or des- 
tination kx^atfohs that they must find additional modes 
of transportation to or from the pre-^et stop. For exam- 4S 
pie, some users drive private vehcles to and from pre- 
set stop kx:atk>ns and park the vehk:les near the stop 
kx:atons. Some mass transportation systems even pro- 
vide vehicle parking facilities near pre-set stop locations 
for such users. so 
[0004] For example, commuter train stops and bus 
stops in and near some cites are often provided with, 
parking lots for train users to park private vehcles. How- 
ever, vehicles In such partying tots typk:ally renr^in . 
parked throughout a large part of the day, and are driven ss 
only in the rTK>ming to brrig the user to the train or bus 
stop and In the evening to take from the train or bus stop. 
Thus, while nrxxJern mass transportation systems can 



result in a reduced number of vehicles on the road at 
any given time, such mass transportation systems do 
not eliminate the need for private vehicles and can result 
in an inefficient use of private vehk;les. 
[0005] Accordingly, there is a need for a system and 
method for the efficient and convenient use of private 
vehicles, such as an efficient and convenient shared ve- 
hicle system and method. Shared vehicle systems can 
provkie more flexibility than other means of public trans- 
portatton. In a shared vehicle system, a number of ve- 
hcles are normally maintained in several designated 
parking areas. Each user is al towed to ptok up a vehicle 
at one parking area, and return the vehicle to the parking 
area nearest to the user's destinatton. The user may al- 
so drive a vehicle out of a designated parking area for 
an errand and return the vehicle to the same designated 
parking area Shared vehicle systems that are used by 
a relatively large number of subscribers should include 
sufficient security measures to protect the vehicles from 
theft and also to protect the user from crime. 
[0006] Shared vehtote systems must be sufftoiently 
convenient to motivate users to emptoy the system. Ac- 
cordingly, vehicle availability within a reasonable time of 
a user's request for a vehicle Is very important to the 
success of such a system. Of course, by maintaining a 
greater number of vehicles In the fleet of shared vehi- 
cles, the availability of a vehk:le at any given time can 
be increased. However, system cost is minimized and 
vehtole-usage efficiency Is maximized with smaller ve- 
hrcle fleets. Accordingly, there is a need for a shared 
vehtole system that maximizes user convenience yet 
minimizes the number of vehicles required In the fleet. 
[0007] In particular, by emp toying vehicles m a shared 
vehtole system or method, additional ecotogicat advan- 
tages can be achieved. Vehicles in a shared system may 
be of many types. They may be the conventior^l petro- 
leum based gasoline or dieset fuel type vehicles. They 
may however be cleaner forms df propulston such as 
methanol or propane powered vehicles, or may be ve- 
htoles powered by hydrogen stored as a gas or metal 
hydrkje. Electric vehtoles may draw energy from batter- 
ies, fuel cells, generators driven by internal combust ton 
engines, or combinations of different energy sources. 
Electrto vehtoles powered by both lead acto and nickel 
metal hydrkJe batteries have shown much promise and 
several manufacturers have produced viable electrk: ve- 
hicles employing these battery technotogies. Electrto 
vehtoles are a good candidate for a shared vehtole, be- 
cause they are among the cleanest arxi quietest forms 
of vehicle, but sharing systems and methods are In no 
way dependent on the use of an electric vehicle, and 
may l>e employed with a number of non electrtoal or hy- 
brid technotogies, Including comrTK>n gasoline power 
[0008] The use of electric powered vehicles In a fleet 
of shared vehtoles, however, presents further complex- 
ities over other alternate power vehicles, for example, 
associated with vehicle charging requirements arxl ve- 
hk;le unavailability during charging times. 
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[0009] Electric vehicles typically require charging 
more often than the convent icxial vehicles require refu- 
eling. Recharging stations are not nearly as available as • 
conventional petroleum rr)otor fuels. Moreover, recharg- 
ing of an electric vehicle typically takes much more time 5 
than refueling a conventional vehicle. Thus, if a conven- 
tional vehicle is present at a designated parking area of 
a shared vehicle system, but does not have sufficient 
fuel to meet a user's travel needs, the vehicle can be 
quickty refueled and made available to the user How- io 
ever, even when an electric vehicle is kJle in a designat- 
ed parking space, It is not available to a user unless it 
has a sufficient existing state of charge (SOC) to make 
the user's Intended trip. Typk:ally, an electric vehicle 
cannot be re-charged. quk:kly enough to make the in- '5 
tended trip if its existing SOC is inadequate. On the other 
hand, if the user intends to make a short trip, the vehcle 
may be capable of making the intended trip even though 
it is not fully charged. Accordingly, there is a further need 
for a system and method for managing shared electric 
vehicles in an optimum fashion and to meet the needs 
of a maximum number of users with a minimum number 
of vehcles. 

SUMMARY OF THE DISCLOSURE 25 

[0010] Therefore, preferred embodiments of the 
present inventkxi relate to shared vehicle systems and 
methods that maximize user convenience and minimize 
the number of vehk:les required in the shared fleet. 30 
[001 1 ] A shared vehcle system according to one pre- 
ferred err^xxiiment of the present invention includes a 
central facility, at least one vehk:le distributkxi port fa- 
cility and a plurality or fleet of vehicles, each having a 
vehicle subsystem. In general, the central station and 3S 
port facility and the vehcle subsystems communicate in 
a manner to allow a user to enter infonmation at a port 
facility. That information is then communicated to the 
central facility, where the informatkxi is processed to se- 
lect a vehicle from the fleet for allocation to the user at 40 
the port facility. The central statkxi communicates with 
the port facility and the vehk:le subsystem, according to 
various embodiments described below, to notify the user 
of the selected vehk:le, to provide secure user access. 
to the selected vehicle, to monitor the location and op- 4S 
crating status of vehicles in the fleet, to monitor the state 
of charge of electric vehicles and to provkJe other func- 
tions described below. 

[001 2] According to one aspect of the invention, allo- 
cation of shared vehicles to users is based, at least in 50 
part, on travel infomnation received from the users. By 
alkx^ting vehcles based on travel inforTT>atkxi the effi- 
cient usage of vehk:les and user convenience can be < 
optimized, for example, to maximize vehicle availability - 
and minimize vehkile downtime. While vark>us embod- 55 
iments related to this aspect of the invention may em- 
ploy any form of shared vehicle, according to further em- 
bodiments of the present invention, vehcle sharing sys- 



tems and methods employing electrk; vehicles in the 
shared fleet and the alkx:ation of electric vehicles to us- 
ers is managed to maximize vehicle availability and min- 
imize vehk;le downtime, taking into account the state of 
charge of a vehk:le and/or the charging rate of a vehicle. 
[0013] According to another aspect of the inventkxi, 
a shared vehk:le system or method provides controlled 
or secured access to and/or enablement of the shared 
vehicles. In preferred embodiments, user identificatkxi 
intornrtatbn is provided to a vehk:le that has been allo- 
cated to a user and such information must nr^tch infor- 
matbn entered by the user in a user interface devk:e 
installed on the vehicle, before the user is alk>wed ac- 
cess to the vehk:le. In yet further preferred embodi- 
ments, a user's personal identificatkxi number PIN must 
be entered by the user in a second interface devk^e in- 
stalled on the vehk;le and must match an expected PIN, 
before the vehicle is enabled for operation. 
[0014] According to yet another aspect of the inven- 
tion, a shared vehicle system and method involves alk>- 
cating vehicles from a group of available vehicles and 
retuming vehk:les to the group upon detectkxt of a park- 
ing state wfiile the vehk:le is kx:ated at a port. A port is 
a V6hk:le staging area where vehk:les may be parked 
prrar to being alkxated to a user. A typbal port contains 
a user kiosk containing a computer terminal for interact- 
ing with the shared vehicle system. Throught this dis- 
ck>sure the term "kiosk", will be used to mean a kk>sk 
with a user terminal. The terms kk>sk and terminal shall 
be used interchangeably herein. In preferred embodi- 
ments, the detection of a parking state is accomplished 
by, for example, the detection of the setting of the vehicle 
in a parking gear, the lack of motion of a vehk^le for a 
perkxl of time, the opening and/or ctosing of a vehcle 
door, or a combination of such events, each of whch 
require no user interaction other than the typk^l actions 
taken to park a vehk:le. 

[0015] According to yet another aspect of the inven- 
tion, a shared vehicle system and method involves pro- 
tecting access and enabling vehicles from a remote lo- 
cation relative to the vehicles, for example, in the event 
that a user k>ses an kjentification code or PIN. 
[0016] According to yet another aspect of the inven- 
tion, a shared. vehk;le system and method involves 
tracking stored energy and/or other operational param- 
eters of vehicles in the shared fleet In prefen-ed embod- 
iments, vehicle parameters, such as stored energy, are 
tracked and processed for purposes of efficient selec- 
tion and allocation of vehicles to users or selection of 
vehk:les for charging. 

[0017] According to yet another aspect of the inven- 
tion is that, if electrk:al vehicles are employed within a 
shared vehk:le system, the electrk^al vehk:les are alk)-- 
cated to users based on the state of charge (SOC) of 
the vehicles, in additkxi to vehk;le kxatkxi. user travel 
informatbn and statist cal analysis of vehcle usage. Ac- 
cording to a further advantage of preferred embodi- 
ments, vehicles are allocated from a defined vehicle 
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search group (VSG) of a port facility. A vehicte search 
group is defined as the set of vehicles that may be allo- 
cated to a user A vehicle search group is determined 
by deciding what time period is acceptable as a vehicle 
search depth time, that is how Jong a predefined wait is 5. 
acceptable before a vehicle becomes available. The ve- 
hicle search group then is ascertained by determining 
which vehicles will be available at the end of the prede- 
fined waiting period. Vehicles within the vehicle search 
group of a port facility include vehicles that are due to io 
arrive at the port facility within the predefined period of 
time or electric vehicles that are due to become suffi- 
ciently charged at the port facilfty within a predefined 
period of time, minus the vehicles within the port that 
have been allocated for departing trips or are scheduled '5 . 
for transport to another port facility. 
[0018] In one preferred embodiment that Includes 
electrical vehicles within the shared vehicle group, a us- 
er is allocated a vehicle having the highest SOC within 
a vehicle search group of vehicles having sufficient SOC 20 
to meet a user's needs. In another preferred embodi- 
ment, a user is allocated a vehicle having the second 
highest (or Nth highest) SOC within a vehicle search 
group of vehicles having sufficient SOC to meet the us- 
er's needs, such that the highest (or N-1 highest) SOC 2S 
vehicles may be reserved for users having travel needs 
which requiring a higher SOCs. In yet another preferred 
embodiment, the system or method has the ability to al- 
locate the highest or hfth highest SOC vehicle, depend- 
ing upon other criteria, such as the tinne of day or day of 30 
the week. Thus, for a certain time period of the day and/ 
or day of the week (for example, between 7:00 a.m. and 
9:00 a.m. on Monday through Friday) the system or 
method may allocate the highest SOC vehk;le in the ve- 
hicle search group is alkx:ated to a user, while at other 3s 
times of the day and/or days of the week, the Nth highest 
SOC vehicle is alkxated to a user. 
[001 9] According to a further aspect of the present in- 
vention, a shared vehicle system and method involves 
transporting or rekx:ating vehk:les from one area or port 40 
having a surplus of vehicles to another area or port hav- 
ing a shortage of vehicles. Vehicles nriay also be trans- 
ported to effectively use storage space for the parking 
of the vehicles. According to yet a further aspect of the 
present invention, a shared vehicle system and method 45 
involves a vehicle carrier for carrying a first vehicle with 
a second vehicle, for example, for relocating the first 
and/or second vehk;le. 

[0020] The above and other aspects, features, and 
advantages of the present invention, will become appar- 50 
ent from the folbwing descriptk>n when taken in con- 
junctkxi with the accompanying drawings in whch pre- 
ferred embodiments of the present invention are shown 
by way of illustrative example. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0021] Referring now to the drawings in which like ref- 
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erence numbers represent corresponding parts 
throughout: " 

Fig. 1 is a schemata diagram representation of a 
vehk;le sharing system according to a preferred em- 
bodiment of the present invention; 
Fig. 2 is a flow chart representation of steps carried 
out to request, select and allocate a vehicle, accord- 
ing to embodiments of the present invention; 
Fig. 3 is a flow chart representation of steps carried 
out for secure access and for enabling vehrcles in 
a fleet of shared vehicles according to embodi- , 
ments of the present inventkxi; 
Fig. 4 is a flow chart representation of steps carried . 
out for vehicle trips according to embodiments of 
the present inventon; 

Fig. 5 is a schematic perspective view of a vehicle 
carrier according to an embodiment of the present 
invention; 

Fig. 6 is a schenr^tc perspective view of a vehicle 
distributkxi port facility according to an enrdxxjiment 
of the present inventon. 

Fig. 7 is a generalized block diagram rep resentatkxi 
of a computer subsystem in a port facility according 
to an embodiment of the present inventon; 
Fig. 8 is a schematk: perspective view of a vehicle 
distributkxi port facility according to another em- 
bodiment of the present invention; 
Fig. 9 is a generalized block diagram representatkxi 
of a central facility according to an embodiment of 
the present inventkDn; 

Fig. 1 0 is a generalized block diagram representa- 
tion of a vehicle subsystem according to an embod- 
iment of the present invention; 
Fig. 1 1 is a graph of the state of charge of a vehicle 
battery versus charge time cun/e; and 
Fig. 1 2 is an illustration of a transfer of vehicles be- 
tween ports; 

Fig. 1 3 is an illustration of a preferred embodiment's 
mounting of a kJentificatbn card reader and a PIN 
entry console; 

Fig. 1 4 is a bkx^k diagram illustrating a central office 
" computer system and the subsystem kk>sk comput- 
ers linked to the central office computer system 
through the Internet; and 

Fig. 1 5 is a flow diagram of the process when a user 
seeks a shared vehcle and interacts with a kk>sk 
connputer. 

DESCRIPTION OF THE REFERRED EMBODIMENT 

[0022] In the folk)wing descriptkxi of preferred em- 
bodiments, reference is "made to the accompanying 
drawings whch form a part hereof; and in whoh is 
shown by way of illustration a specific embodiment in 
which the inventkxi may be practced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural changes may be made without departing from the 
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scope of the preferred embodiments of the present in- 
vention. 

[0023] TTie present invention relates, generally, to 
systenDs and methods for sharing a fleet of vehicles 
among a plurality of users, and various aspects of such 
systems and methods Including optimizing vehicle allo- 
cation, vehicle tracking, security, and charging and man- 
aging of shared electric vehicles. As discussed above, 
in a shared vehicle system, a number of vehicles are 
normally maintained in several designated parking are- 
as. Each user is allowed to pick up a vehk:le at one park- 
ing area, and return the vehicle to the parking area near- 
est to the user's destination or return the vehicle to the 
same designated parking area. 
[0024] To successfully attract people to subscribe and 
become users of a shared vehicle system, the system 
must be sufficiently convenient and inexpensive. More 
particularly, users should be able to pick up a vehicle at 
a convenient location and with minimal or no waiting 
time. The system should be easy and inexpensive for 20 
the user and cost effective tor the system administrator 
to operate. To have minimal environmental impact, the 
system should be capable of addressing the above --^ 
needs and employing clean means of transportation, 
such as electric powered vehicles, as its primary shared 
vehicle. 

[0025] Preferred embodiments of the present inven- 
tion relate to shared vehicle systems and methods 
which address the above-described needs and whch 
address additional needs and provide additional advan- 30 
tages discussed bebw. As will become apparent from 
the discussion bek>w some embodiments pertain only 
to sharing systenDs containing at least some electrical 
vehicles. Those embodiments of the inventkxi relate to 
charging or state of charge (SOC) of electric vehk;les 3S 
and may be implemented with or without various other 
aspects relating to, for example, vehk:le allocation, 
tracking, and securing. Similarly, embodiments of the in- 
vention relating to vehicle alkx:ation aspects may be ivn- 
plemented with or without varwus other aspects such 40 
as vehicle charging, tracking and securing, and embod- 
iments relating to vehicle securing may be implemented 
with or without other aspects such as vehicle tracking, 
alkx^ation or charging. 

[0026] A schematic representation of a shared vehcle 
system 10 according to a preferred embodiment of the 
present invention is shown in Fig. 1 . A system 10 ac- 
cording to the Fig. 1 embodiment includes a central fa- 
cility 12, at least one vehicle distributkyi port facility 14 
and a plurality or fleet of vehicles 16 (one of whch is so 
shown in Fig. 1), each having a vehicle subsystem 18. 
In general, the central station and port facility and the 
vehicle subsystems communicate In a manner to allow* 
a user 20 to enter informatkxi at a port facility 14. That 
information is then communicated to the central facility ss 
12, where the infornration is processed to select a vehi- 
cle from the fleet to allocate to the user at the port facility 
14. The central station 1 2 communicates with the port 



facility 14 and the vehcle subsystem 18. according to 
varbus embodiments described below, to notify tfie user 
of the selected vehk:le, to provkJe secure user access 
to the selected vehble, to rrxxiitor the kx:atkxi and op- 
erating status of vehbles in the fleet, to monitor the state 
of charge of electrb vehicles and to provide other func- 
tions described bebw. 

Selection and Allocation off Sharing Systems 
Containing Electric Vehbles: 

[0027] . According to one aspect the present inven- 
tion, systems and methods for sharing electrk: vehicles 
Involve selecting and albcating vehcles to users, based 
on a combinatbn of factors for maximizing efficiency 
and user-convenience. Such factors nr^ay include vari- 
ous combinations of the following: the kx:ation of the ve- 
hicles within the fleet, state of charge of the vehicles, 
the distance whbh the user expects to travel, the perbd 
of time that the user' expects to use the vehble, the us- 
er's expected destination, statistbal analysis of vehicle 
use patterns and the identity of the user, the number of 
indivbuals waiting for vehcles in the port, and the 
number of vehicles present In the port. 
[0028] A user desiring to obtain the use of a vehicle 
1 6 arrives at a flrst port facility 1 4 and enters a request 
for a vehble and other Informatbn into a computer sys- 
tem. The information may include the destination port 
or kbsk. The information may also include the additional 
distance and/or time that the user expects to travel be- 
yond the nomnal distance and/or time to reach the des- 
tinatbn port facility, for exampte, to conduct errands or 
other excursbns. The infomiatlon may further include 
user bentrflcatbn informatbn, for example, read from a 
card key 21. smart card, magnetic strip, fingerprint, ret- 
inal scan or other machine-readable method of bentifl- 
cation. 

[0029]" In a preferred embodiment, described with ref- 
erence to the system In Fig. 1 and the flow chart of Fig. 
2, a user enters bentification information by swiping a 
card key 21 (or other machine-readable token) past a 
reader, step 22. The informatbn is received by the sys- 
tem in step 24 and. In step 26, the user enters travel 
informatbn (such as destinatbn, added distance and^r 
added time) with a keyboard, touch-screen. nx>use or 
other suitable user interface. In step 27 the availability 
of a vehicle Is checked, and If a vehicle Is available step 
28 folbws, if not step 40 will be next. 
[0030] In the present preferred enrHxxiiment, the com- 
puter system at the port facility 14 is programmed to 
prompt the user to enter the above-noted travel infor- 
matbn, upon the user registering by swiping the card 
key 21 (or other token) past the reader. The computer 
system may display destination optkxis and/or addition- 
al time or distance optbns. Thus, the display may 
prompt the user to, for example, select or clbk an bon 
for a proposed destinatbn port facility. In addition other 
icons for selecting a proposed additbnal number of min- 
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utes or miles of expected travel beyond the route to the 
destination port may be displayed. By selecting the ad- 
ditional Icons the user may inform the system that the 
user will have an errand trip. An errand trip is a detour 
from the regular route that would be taken in traveling 
between points. For example a user of a vehicle may 
travel directly to a destination or they may take a side 
excursion for example to pay a bill or to buy a newspa- 
per. Such side excursions are errand trips. The user can 
select different Icons notifying the system that, for In- 
stance an errand trip will take an additional 45 minutes 
and add an additional 1 0 miles beyond what wouki be 
expected If the direct route to the destination were taken 
without the errand trip. In yet further embodiments, a 
map Is displayed to the user and the user is prompted 
to Identify locations on the map corresponding to a des- 
tination and/or side trip kx:ations or zones. It can be very 
important to the scheduling and altocatlon of vehcles to 
altow for excursions such as errand trips. Efficient allo- 
cation of vehcles Is easier if vehrcle trips can be pre- 
dicted with greater reliability and accuracy. Embodi- 
ments of the vehicle sharing system and method include 
implementatkxis, which reward users for accuracy, for 
example if the user returns the vehcle within 5 minutes 
of the planned return lime the user may get an 'accurate 
return time' discount. Users way also get a discount if 
they give notice of unexpected delays. For example If 
the users were charged a per hour rate a user wouki be 
charged for a whole hour if they retumed a vehicle 10 
minutes late, whereas if they gave notrce of their late 
return, so that the vehicle could be reallocated during 
the proper time frame, they might be charged for onfy a 
portion of an hour Similar discounts might be given for 
accurately predk:ting the number of miles driven. By ac- 
curately predk;tlng the distance to be driven the system 
could nx>re accurately predk:t, at the beginning of a trip, 
the state of charge (for electrcal vehicles) that will be 
present when a vehicle Is retumed, thus enabling more 
effrcient allocatk>n of vehcles and charge facilities. 
[0031] The lnformatk)n entered by the user at a port 
facility 14 is communicated to the central facility 12. In 
additkxi, the central facility 12 receives Information 
transmitted from the vehicle subsystem 18 In each ve- 
hicle 16, relating tothe kx:atkyi, parking state, odometer 
information, state of charge SOC of the vehicle, trip time, 
and various other trip information ar>d statistics. Based 
on the informatbn received from the first port facility 14 
and from the vehk:le subsystems 18, the central facility 
12 selects a vehk:le from among the fleet to allocate to 
the user, as shown In step 28 in Fig. 2. 
[0032] To select a vehk:le, a vehk:le search group is 
defined for the first port facility. The vehkile search group 
preferably Includes vehcles 16 located and parked at 
the first port facility 14 that are not presently allocated 
to other users. The vehicle search group may also In- 
clude vehicles 1 6 expected to arrive at the first port fa- 
cility within a pre-defined time period. Vehicles sched- 
uled to leave the port for transfer to another port or oth- 



erwise can be removed from the vehcle search group, 
as can vehicles that have insufficient SOC for the in- 
tended use. The pre-defined time perkxi is preferably 
selected to minimize user-waiting time, yet rrmimize 
s vehcle usage efficiency, or minimize energy usage or 
vehcle emissons. A pre-defined time perkxJ of, for ex- 
ample, about ten minutes may be sufTcient to Improve 
vehcle usage efficiency, without significantly Inconven- 
iencing users. 

10. [0033] Vehicles 16 with an insufficient SOC to make 
the trip to the expected destinatkxi, including any addi- 
tional distance and/or time entered by the user and an 
additional nnargin for error or unexpected travel may be 
excluded from the vehcle search group. Thus, a deter-. 

IS minatkxi is made of the total charge necessary to safely 
make the trip, based on the expected destlnatkjn, addi- 
tional distance and/or additk)nal time Infonmatkxi en- 
tered by the user. The total necessary charge Is com- 
pared with the SOC informatk)n received from vehicles 

20 present at the port facility or otherwise within the vehicle 
search group of the first port facility. Vehcles that have 
SOCs bek3w the total necessary charge are excluded 
from the selectnn process. However, vehicles 16 which 
are in the process of being charged at the first port fa- 

^5 cillty 14 may be included in the vehicle search group. 
provkJed that they will be suffrciently charged within a 
pre-defined time perkxJ. (which may be the same pre- 
defined time period as noted above or a second time 
perkxJ) as may vehcles arriving at the port form com- 

^ pleted trips, or from being transported to the port. 

[0034] If a group of more than one vehcle 1 6 is in the 
vehk;le search group of the first port facility and has suf- 
ficient SOC to make the requested trip, then, according 
to one embodiment of the present Inventkxi, the vehicle 

35 with the highest SOC within the group is selected and 
allocated to the user It has been found that selecting 
the higher SOC vehicles first, typcally Improves the ef- 
' ficlency of the charging facilities by utilizing the charger 
in its more efficient linear range between 212 and 214 

40 (see Fig. 11). 

[0035] However, In the event that a user enters a re- 
quest to make a long distarce trip and, thus, requires a 
vehcle having a relatively high SOC, It wouM be advan* 
tageous to have a relatively high SOC vehicle available 

45 for the user, without requiring the user to wait a tong pe- 
riod of time. Accordingly, in further preferred embodi- 
ments, the vehcle having the highest SOC within the 
above-defined group Is reserved for the long-distance 
user and the second highest SOC vehcle Is alkx^ted 

50 to other users. Of course, if the group consists of only 
one vehcle, then that vehcle is allocated to the user, 
rather than reserving the vehcle for a further prospec- 
tive kxig^iistance user 

[0036] While the above alternative embodiment refers 
55 to reserving the highest SOC vehcle within the defined 
group for a prospective long-distance user, other em- 
bodiments may reserve the highest and second highest 
SOC vehicle and so forth. Moreover, different numbers 
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of vehicles may be reserved tor long-distance users de- 
pending upon the lime of the day or the day of the week, 
statistical or simulated use pattems. vehicle reserva- 
tions, or a variety of other factors. In preferred embodi- 
ments, statistics of users driving practices and habits at 
each port facility can be collected and analyzed to de- 
termine the optimal number of vehicles which should be 
reserved for long-distance users for any given port fa- 
cility, day and time. In yet further preferred embodi- 
ments, the system and method switches between a rou- 
tine of selecting the highest SOC vehicle within the 
group and a routine of reserving one or more of the high- 
est SOC vehicles within the group for long-distance us- 
ers, based on expected usage patterns or statistical 
analysis of actual or simulated usage patterns^ 
[0037] A port facility can contain a plurality of charging 
facilities 1 69 that are used to recharge the batteries of 
electrical vehicles. Typically battery/charging systems 
for electrical vehicles have a characteristic as shown in 
the SOC versus time graph 210 as shown in Fig. 11. 
Between points 21 2 and 21 4 on the graph, the charging 
of the battery is essentially linear. Between points 214 
and 216, the charging of the battery approaches 100% 
charge exponentially and therefore the amount of 
charge obtained per unit time decreases. By allocating 
vehicles with a higher state of charge to users, instead 
of merely allocating vehicles with a sufficient charge for 
the users requested use, the vehicles within a central 
facility will tend to be used before the charge point 21 4 
on the graph is reached. By charging vehicles in the lin- 
ear region between 212 and 214, more effective use of 
the charging facilities is made than by charging vehicles 
in the range between 214 and 216. This method of allo- 
cating vehicles with the highest charge, however may 
be modified, as previously described, in order to provide 
vehicles for long trip use (i.e. vehicles charged between 
214 and 216 on the state of charge graph). In cases 
where vehicles for long trips are needed the vehicles 
with the second highest charge could be allocated for 
use in order to preserve the most highly charged vehicle 
for the long trip user. In cases where a greater demand 
for long trip vehicles was present, the vehicle with the 
second highest charge might also be reserved. The al- 
location of vehicles can be modified by statistical or sim- ■ 
ulated vehicle use in order to make the most efficient 
use of charging facilities, while at the same time attempt- 
ing to accomnrxxJate the need for vehcles with high 
state of charge for long trips. 

[0038] Once a vehicle is selected based on the above- 
noted routines, the vehicle is alkxrated to the user and 
the partcular vehicle is kientified to the user, as shown 
at step 30 in Fig. 2. The vehcle may be kientified to the 
user by identifying the kx:atk>n of the vehicle; e:g; a 
parking space number, or by a number, e.g. license 
plate, displayed on the vehk;le. If the selected vehcle is 
due to arrive at the port facility or is due to be sufficiently 
charged at the port facility within the above-noted pre- 
defined time perkxte, then the user is notified of the ex- 



pected wait time and is asked if they will wait for the 
availability of the vehicle whk:h will arrive at the port. In 
preferred embodiments, the user is provided with an op- 
tion to accept or decline, for example, by a displayed a 

5 command prompt to accept or decline the proffered ve- 
hble. If the user declines the vehcle, step 32, the sys- 
tem returns to an idle condition to await the next user, 
step 34. If the user accepts the vehicle, step 36, the user 
may then pick up the vehcle at the port facility 14, step 

10 38. 

[0039] Vehicles may arrive at the port in two distinct 
ways. A vehcle way arrive at the port if the user comr . 
pletes a trip and returns the vehcle to the port. A vehicle 
may also be rekx:ated from another locatk)n. Fig. 1 2 is 

fs an illustration of a transfer of vehcles between ports. An 
attendant drives a first vehicle 230. A second vehicle 
234 is towed behind the first vehicle 230, attached to the 
first vehcle via a towing mechanism 236. Couplings for 
the attachment of the towing mechanism may be in- 

20 stalled on the front and rear of shared vehicles (e.g. 230, 
234) so that any number of like vehcles may be con- 
nected in series for the purpose of rekx:ating them from 
one port to another. The couplings installed on the- ve- 
hcles may also be used to transport other vehcles. Fig. 

2^ 12 illustrates a motor scooter 240 being transported on 
the second vehicle 234. The Scooter 240 is mounted on 
a lifting mechanism 242 Other vehcles, for example a 
bcycle, or motorized bicycle may also be transported in 
a similar manner. If a port attendant tows a second ve- 

30 hcle with a motor scooter, as shown in Fig. 1 2 then when 
the attendant has reached the destination port the at- 
tendant may uncouple the motor scooter and rkie it back 
238 to the embarkatkxi port, thus relocating two vehicles 
in one trip. The motor scooter may also have a carrying 

3S bracket for transporting towing mechanisms back to the 
origination port along with the attendant. Electronic tow- 
ing mechanisms have also been derrxxist rated. Such 
mechanisms cause vehcles behirxJ a lead vehcle to fol- - 
tow the lead vehcle through electronic means. Such 

40 electronc towing mechanisms however are still in the 
experimental stage, an6 no commercial systems are 
available. 

[0040] If no vehcles are within the vehicle search 
group and have sufficient SOC to meet the user's needs, 

4S then the system determines that a vehicle may need to 
be relocated from another port facility to the first port for 
the user, as shown in step 40. In such an event, infor- 
nr^tton is displayed to the user relating to the expected 
time of arrival of a relocated vehcle or user retumed 

so vehcle, step 42, and is provkled with an opportunity to 
accept or decline to wart for the vehicle. If the user de- 
clines, step 44, then the system returns to an idle con- 
dition, step 34rand awaits the next user. If the user ac- 
cepts the wait time, step 46, then the user waits, step 

ss 48 until the vehicle arrives, step 50. Upon arrival of the 
vehcle. the user is prompted to confirm the request for 
the vehicle. If the user does not confirm the request with- 
in a preset time period, for example, five minutes as 
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shown in step 52, then the system returns to an idle con- 
dition, step 34. It. however, the user timely confirms the 
request, step 54, then the user may pick up the vehicle, 
step 38. 

[0041] Vehicles may be relocated from one port facil- 5 
ity to another in a variety of manners. For example, an 
attendant may simply drive the vehicle from one facility 
to the other However, the attendant performing the re- 
location would then be displaced from his original loca- 
tion. Accordingly, two attendants may drive two vehicles io 
to from one port to the next, leave one vehicle at the 
destirration port and then both attendants may return to 
their original port in the other one of the two vehicles. 
However, that process requires two attendants to trans- 
port a vehicle between facilities. Accordingly, in a pre- 
f erred embodiment, some or all of the vehicles within 
the fleet are provided with towing bar connectors and 
each port facility is provided with towing bars for con- 
necting two vehicles together In this manner, one vehi- 
cle may be readily connected to another and towed to ^ 
a remote port facility by a single attendant. The attend- 
ant may then disconnect the connected vehicles, leave 
one of the vehicles for the user and return to the original 
port facility with the other one of the two vehicles. Alter- 
natively a secondary vehicle, for example a motor scoot- 2S 
er, may be secured to the second vehicle. The motor 
scooter can, upon delivery of the vehicles, be used to 
transport both the attendant and the towing bar equip- 
ment thus allowing the two connected vehicles to remain 
at the destination port while the attendant and the towing 30 
equipment depart. 

Controlling Access to Allocated Vehicles : 

[0042] According to another aspect of the present in- 3S 
vention, systems and methods for sharing vehicles in- 
volves controlling access to each allocated vehicle, so 
that access is allowed only for the user to whom the ve- 
hicle had been allocated. Security measures are imple- 
mented with the use of card keys (or other suitable ma- 40 
chine-readable tokens) and personal identificatkxi num- 
bers (PINs) issued to each user Thus; according to this 
aspect of the invention, a user registers at a port facility, 
such as by swiping a card key (or other token) or by en- 
tering klentification informatkxi through other suitable ^ 
user interface means, such as described above with re- 
spect to step 22 of Fig. 2, and a vehcle is selected by 
the central facility. If the vehcle fleet includes elect rk; 
powered vehicles, then the select kxi of the vehcle is 
preferably performed in accordance with the above de- so 
scribed vehcle selection and alkx:ation aspect of the in- 
vention. However, other embodiments may empk>y oth- 
er suitable selection routines. 

[0043] Once a vehcle is selected, identified and ac- 
cepted by the user, such as described above with re- ss 
spect to steps 28, 30 and 36, then the user's identifica- 
tkxi information is sent to the vehicle subsystem 1 8 in 
the selected vehicle from the central facility 12, as 



shown in step 56. In preferred embodiments, the infor- 
matbn is encrypted for security and addressed to the 
vehcle subsystem of the selected vehcle. Upon receipt 
of the user identificatkxi infornoation, the vehcle subsys- 
tem starts a counter for timing a preset time perkxi, such 
as five minutes, as shown in step 58, and stores the 
identification information in memory, as shown in step 
60. 

[0044] Meanwhile, the user walks to the vehicle, such 
as in step 38. With reference to the flow chart of Fig. 3, 
if the user arrives at the vehcle within the preset time 
perkxj, such as five minutes, the user then enters tien- . 
tificatkxi informatkxi, for example, by swiping a card key 
(or other machine-readable token) past a reader mount- 
ed on the selected vehicle, step 62 in Fig. 3. In preferred 
embodiments, the card key (or token) is the same card 
key (or token) used during the user registratkxi at the 
port facility. If the identificatkxi infomnation (card key or 
token) is not read by the reader within the preset time 
perkxj, then the user identificatkxi routine is disabled on 
the vehicle subsystem, step 64 and the vehcle is des- 
ignated as being available for further users, step 66. 
[0045] If, on the other handi the user's kientification 
information (card key or token) is read within the preset 
time period, step 68, then the vehicle subsystem com- 
pares the stored identification informatkxi received from 
the central facility with the identrficaton informatkxi en- 
tered by the user (read by the card or token reader), as 
shown in step 70. If the kientification information does 
not match, then the user is denied access to the vehk:le, 
step 72, 

[0046] If the identification information received from 
the central facility matches the kientrficatkxi informatkxi 
(card key or token) entered by the user, then the user is 
allowed access to the vehicle, as shown in step 74 and 
a counter starts timing a preset time perkxJ, such as five 
minutes, as shown in step 76. In preferred embodi- 
ments, the vehicle subsystem employs an electronc 
door lock that is controlled to selectively unlock the ve- 
hcle, step 78, to altow access to the vehicle interior In 
addition, counters within the vehcle subsystem are set 
and started for counting the number attempts of entering 
a personal kJentificatbn number PIN. step 80. and for 
timing a preset time perkxi by which a correct PIN must 
be entered, such as 200 seconds, step 82. 
[0047] After gaining access to the vehicle, the user 
enters the vehicle and closes the vehicle door, step 84. 
The user is provided with an opportunity to enter a PIN 
in a user interface and display devce mounted, for ex- 
ample, in the center console, dashboard or overhead 
console of the vehicle. If the user does not enter the cor- 
rect PIN within a preset number of attempts, for exam- 
ple, five attempts,- as shown in step 86, or within a preset - 
time period, such as 200 seconds as shown in step 88, 
then the user's request for a vehicle is canceled, step 
90 and an error message is displayed on the user inter- 
face and display devce, step 92. Thereafter when the 
user leaves the vehcle, step 94, and cbses the doors. 
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the doors are automatically locked, step 96, and the ve- 
hicle subsystem returns to an idle state, step 98. The 
vehicle is then made available for further users, as 
shown by the connection to step 66. If, on the other 
hand, the user enters the correct PIN within the preset s 
number of attempts and the preset time period, step 
100, then the vehicle subsystem enables the vehicle 
and the user may operate the vehicle, step 102. 
[0048] In one preferred embodiment both the user's 
identification data and PIN are read from a user's iden- io 
tification card and communicated to the vehicle to be 
allocated to the particular user. As soon as the user's 
identification data and PIN are communicated to the ve- 
hicle to be allocated to the particular user, an authorized 
user may drive the vehicle on a trip without any further 
communication between the vehicle and the central fa- 
cility. Upon use of the proper identification card and en- 
try of a correct pin within the vehicle, the vehicle is ready 
to drive. The identification card reader 246 may be lo- 
cated on a window as shown Fig. 13. The PIN entry is ^ 
accomplished by means of an input and display device, 
which may be mounted in a center console within the 
vehicle as shown in Fig. 13. In another preferred em- - 
bodiment, the determination of whether the entered PIN 
is correct or not is nnade at the central facility, for addi- 2S 
tional security. In this case the valid pin is not sent to the 
vehicle, instead the user in the vehicle enters a PIN 
which is then sent to the central facility for validity de- 
termination. If the PIN is valid then the central facility 
sends a notification of valid PIN to the vehicle. In partic- 30 
ular, the central facility 12 preferably includes or oper- 
ates with a database, table, algorrthm, number encoded 
on the user's identification card, or the like which asso- 
ciates each user's klentificatkxi tnf ormatk>n (card key or 
token) with the user's personal kJentrfication number ss 
PIN. Accordingly, upon receiving the requesting user's 
identificatkxi information, the central facility 1 2 obtains 
that user's PIN, for example, by comparing the identifi — 
cation information with corresponding data base entries 
and reading PIN informatk>n associated in a database 40 
with the identificaton information. Furthermore, when 
the user enters a PIN in the user interface and display 
device in the vehk;le, steps 86 or 100, the vehicle sub- 
system transmits the entered PIN to the central facility. - 
The central facility then compares the PIN received from 45 
the vehrcle subsystem with the PIN retrieved from the 
database, table, algorithm, user's identification card, or 
the like. If a sufficient match exists, then the user is con- 
sidered to have entered a correct PIN. The central facil- 
ity may then send an enabling connmand to the vehksle, 50 
acknowledging that a correct PIN has been entered at 
the vehicle and the vehcle may be driven. The correct 
pin can be maintained in the vehk^le subsystem 18 for 
later identificatkxi of the user and enabling of the vehi- 
cle, even if the vehk:le were not in communk:atkyi with ^ 
the central facility. 

[0049] Accordingly, preferred embodiments provkle 
multiple levels of security. A first level of security is pro- 



vkjed by the fact that a valid ID card is required even to 
enter the port facility. A second level of security is pro- 
vided by the requirement that. a user must proffer the 
proper dentification at the kiosk 14 to be assigned a ve- 
hicle. A third level of security is provided at the vehicle 
where the user must enter valki identification informa- 
tion (for example, by swiping a card key or token) to gain 
access to the vehicle. A fourth level of security is pro- 
vided by the requirement that, once the user gains ac- 
cess, the user must input a PIN that corresponds to the 
same user associated with the identification informatkxi. 
Moreover, each of these entries must be made within a 
preset period of time. These multiple levels of security 
reduce the risk of unauthorized entry and unauthorized 
use or theft of the vehicles. Thus,, users are provkied./ 
with a more secure environment within the vehicles and 
the vehicle owners and system administrators are pro- 
vkjed with a reduced risk of vehcle theft or misuse. 

Vehicle Trip and Condrtkxi Monitoring : 

[0050] In accordance with further aspects of the 
present invention, after the user engages the engine as 
discussed above with respect to step 102. the user may 
shift into drive, step 104 of Fig. 4, to begin the user's 
requested trip. During the course of the trip, the vehicle 
subsystem monitors various parameters associated 
with the vehkrie, for example, the location of the vehk^le, 
the state of charge SOC of the vehk:le (in electrical ve- 
hcles) and other operatkxial parameters such as odom- 
eter reading, speed, and actual usage or drive time, as 
shown in step 106. Information, including kx:atkxi infor- 
matk>n, SOC and other operational information, such as 
whether the vehicle is moving and rf so at what speed, 
whether the vehicle is charging, the odometer reading, 
the state of charge of the battery system, is preferably 
transmitted from the vehicle subsystem 18 to the central 
facility 12 at perkxiic or non-periodk; intervals. In this 
manner, the central facility may readily track each vehi- 
cle in the fleet and render selection and alkx3tkxi de- 
terminatkjns based on vehcle kx:ation and SOC infor- 
matk>n for each vehicle, as described above. In additon, 
the central facility may rrnxiitor the SOC of fleet vehicles 
for purposes of waming users and port facility attend^ 
ants to re-charge a vehicle. 

[0051] The user interface and display device within 
the selected vehk;le displays various information to the 
user, for example, usage time, or warnings relating to 
the SOC or other vehicle parameters. notk:es or travel 
informatk>n sent from the central facility, as shown in 
step 108. For example, the central facility may send a 
waming to a vehicle, to inform the user that the SOC of 
the vehk^le is low or has experienced an unusual fluctu'' 
ation. The user may be informed to retum the vehk:le to 
the nearest port or kiosk or to simply connect the vehicle 
to a charger, upon the user's scheduled retum. 
[0052] The user interface arxJ display device within 
the selected vehcle may also be used to transmit mes- 
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sages to the central facility. A group of preset messages 
such as flat tire', "vehicle inoperative" or "send help" 
may be transmitted from a user interface and display 
console within the vehicle by the user selecting which 
message to transmit to the central facility. . 
[0053] In further preferred embodiments, the vehicle 
subsystem may include or operate with a locator such 
as global positioning system (GPS), dead reckoning 
system, radio beacon triangulation system, or a variety 
of other techniques for providing tracking and route in- 
formatkxi. The user interface and display device may 
be used to display map and route information, in accord- 
ance with well known tracking and routing systems. 

Vehk:le Parking and Return : 

[0054] At some point in the duratkxi of the user's trip, 
the user will stop the vehicle and place the vehicle in a 
parking gear as shown in steps 110 and 112. In preferred 
embodiments, the vehk;le subsystem 1 8 includes a sen- 
sor system for sensing such an event. Upon sensing that 
the trartsmission is set in a parking state and/or the ig- 
nition or power is turned off, the vehicle subsystem 18 
transmits a parking state signal to the central facility. 
Once the vehicle is placed in a parking state, the vehcle 
is turned off and disabled, as shown in step 114, until 
the user reenters the correct user identification and cor- 
rect PIN. If the vehcle is at a port facility however and 
the vehicle is placed in a parking state, the vehicles is 
turned off and disabled, the user must go through the 
vehicle alkx^ation process again if they desire to use a 
vehicle further. At the port the vehcle is returned to the 
pool of available vehicles when it is placed in the park 
state. 

[0055] In further preferred embodiments, the vehicle 
sut)system 18 includes or operates with sensors for 
sensing the user exiting the vehcle. step 116, such as 
sensors for sensing the driver-side door opening and/or 
closing after the vehk:le is set in a parking gear. Further 
embodiments may employ other suitable sensors for 
sensing a parking condition, including, but rx>t limited to 
a pressure sensor for sensing presence of weight on the 
driver's seat, a sensor for sensing the setting of the park- 
ing brake, or the lack of nrx^tkxi for a predefined period 
of time, or combinatkxis thereof. In yet further embodi- 
ments, the user may simply enter a rx^tice indk^ating that 
the vehicle is parked in the user interface and display 
device in the vehicle. 

[0056] Information relating to the parked state of the 
vehicle is transmitted from the vehk:le subsystem to the 
central facility. However, further information is needed 
to determine whether the vehk:le is parked and being 
returned to a port facility or is merely temporarily parking 
while the user is conducting an errand. Accordingly, in 
preferred embodiments, if the vehk:ie is in a parked 
state, then the vehcle's locatkxi is determined, as 
shown in step 118. As discussed above, any suitable 
vehicle tracking system may be employed to track and 



determine vehk:le kx^tions, including, but not limited to, 
GPS systems, a Teletrac system (Teletrac is a trade- 
mark of Teletrac, Carlsbad California), or the like. 
[0057] If the vehicle is determined to be within a port 
. facility when placed in a parked condition, then the ve- 
hicle subsystem is controlled to lock the vehicle doors 
within a preset time period, for example, 30 seconds, 
after the last vehicle door is ck>sed. step 120. The vehi- 
cle subsystem then retums to the klle conditkxi, step 
122, and awaits alkx:ation to a further user 
[0058] If the vehicle is determined to be outside of a 
port facility when placed in a parked condition, then the 
vehk:le subsystem is controlled to lock the vehcle doors 
and disable the vehk:le within a preset time period, for 
example, 30 seconds, step 124. The vehicle subsystem 
also may be controlled to kx;k the vehicle doors after a 
door has been opened or after the ignitkxi has been 
tumed off. However, instead erf returning to kjle condi- 
tion, the vehicle subsystem remains programmed to al- 
k>w access and the enabling of the vehicle to the user 
with the same user identificatkxi and PIN, as shown in 
step 126. In this regard, when the user retums to the 
vehble, the user may input the same kientrfication data 
(for example, by swiping the same card or token) there- 
by entering the same PIN that was previously entered 
by the user or sent to the vehicle via the central system, 
as shown in step 1 28. Thereafter, the process of com- 
paring identrficatk>n informatkxi and processing PIN in- 
formation is carried out similar to that described above 
with respect to Fig. 3, beginning at step 70. 
[0059] Thus, in accordance with a further aspect of 
the present invention, the parking state of each vehicle 
1 6 is sensed and a determination is made as to whether 
the vehcle has been returned or is merely temporarily 
parked during a user's trip. The tdentificaton information 
and PIN data required to access the vehcle remain the 
same, unless it is determined that the vehicle has been 
returned and parked at a port facility. Accordingly, a ve- 
hicle may be automatically reallocated to another user 
upon the detemninatkxi that the vehcle has been parked 
and returned to that facility. 

Safety and User Errors : 

[0060] According to further aspects of the present tn- 
ventk)n, safety measures are implemented to address 
srtuatbns in whch a legitimate user inadvertently enters 
the wrong PIN more than the allowed number of at- 
tempts, fails to enter the information within the preset 
time perkxi, loses a card key or kx:ks the card key inskJe 
of the vehicle. In the event that a legitimate user is in- 
advertently denied access to or enablement of a vehcle, 
then the user may contact the central facility by suitable 
means, including,- but not limited to, telephone, portable 
Internet connection, or other communcatkxi device. 
Upon verification of the user's identity, the central facility 
transmits a command to the user's vehicle to instruct the 
vehcle subsystem to unlock and enable the vehcle for 
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the user, [f the user is at a remote location from the ve- 
hicle, for instar^ce at a public telephone, the enablerDent 
comnnand may have a delayed enabling effect in order 
to allow the user to return to the vehicle before it Is en- 
abled. 

[0061] User identity may be verified, for example, by 
requesting that the user provide certain personalized in- 
fornnation for comparison with such information ob- 
tained from the user when the user originally subscribed 
to the system. In addition, the location of the vehicle may 
be determined, as noted above, and may be compared 
with the expected vehicle location, based on the travel 
information entered by the user upon requesting the ve- 
hicle. 

[0062] In addition the vehicle possesses a 'fail safe' 
operations mode. Once a vehicle is checked out by a 
user it will continue to operate for the balance of the us- 
er's trip, even if the communications unit which main- 
tains communication with the central facility should fail, 
or should the central facility cease furiction for any rea- 
son. Thus there is no condition where loss of communi- 
cations between the central facility and the vehicle will 
cause the vehicle to become disabled. 
[0063] The vehicle may also be disabled in some cir- 
cumstances, such as when the vehicle is reported as 
stolen, or when proper authorities seek to immobilize the 
vehicle. The vehicle may also be enabled in an emer- 
gency, for instance if the vehcle is in danger of being 
damaged if it ts not moved, such as a spreading fire in 
a nearby facility. 

Vehicle Rekx:atkxi : 

[0064] As discussed above. In preferred embodi- 
ments, vehcles may be relocated from one port facility 
to another, to meet user demands or to relieve a facility 
of an cversuppty of vehicles. Also as discussed above, 
in a preferred embodiment, some or all of the vehk;les 
within the fleet are provided with towing bar connectors 
and each port facility is provk^ed with towing bars for 
connecting two or more vehk:les together In this man- 
ner, one vehcle may be readily connected to anc^her 
and towed to a remote port facility by a single attendant. 
The attendant may then disconnect the connected ve- 
hicles, leave one of the vehk;tes for the user and return 
to the original port facility with the other one of the two 
vehicles, or on a vehicle, for example a motor scooter, 
mounted on one of the vehKles. 
[0065] The ability to connect vehicles, rekx^ate the 
connected vehcles and disconnect the vehcles at the 
relocation in a time efficient manner requires a tow bar 
and connection system that can be operated quckly and 
easily. Accordingly in preferred embodiments some or ■■ 
all of the fleet vehk:les are provided with tow bar con- - 
nectors and each port facility is provkjed with at least 
one tow bar designed for quick and easy connectkxi to 
the vehicles. The relocation aspect becomes more com- 
plex, however, when the fleet of vehicles includes a va- 



riety of different types of vehicles, such as four-wheel 
vehk;les, two-wheel vehk;les, and/or three-wheel vehi- 
cles. In such embodiments, it is preferred that a tow or 
carrier mechanism be provided to altow various types of 
5 vehk;les to be towed or carried by other fleet vehkiles 
from one port facility to another 
[0066] TTius, for example, Fig. 5 shows an exarrtple 
of a carrier bracket 1 30 for connection to a standard tow 
bar receptacle on the rear of a vehrcle. and whk:h is con- 
10 figured to carry a further vehcle, such as a two-wheeled 
or three-wheeled vehicle. More particutariy, the bracket 
1 30 includes a first 'L' -shaped member 1 32 and a sec- 
ond, snnaller 'L'-shaped member 134 coupled in a slKi- 
ing relationship with the first member 132. Each 'L' 
shaped member 1 32 and 1 34 includes a vertical leg and 
a horizontal leg. The vertical leg of the member 134 is 
coupled, by brackets 1 36 to the vertcal leg of member 
1 32 and is slidable in the directkxi of arrow 1 38. akxig 
the vertical dimenskxi. The vertical leg of member 1 34 
is connected to a flexible band 140. The opposite end 
of the strap 140 is wound around a spool or reel 142. 
[0067] In operatk>n, the horizontal leg 144 of member 
1 32 is shaped to fit within and connect to the standard 
tow bar receptacle on the back of at least some of the 
fleet vehicles. The horizontal leg 146 of member 1 34 in- 
cludes a key or pin receptacle aperture 148 and is con- 
figured to couple to an inverted 'U'^haped bracket 
rDounted to the underside of the vehk:le 1 6' to be carried. 
For example. Fig 5 shows an inverted 'U '-shaped 
bracket 1 50 mounted to the underskje of a motorized 
two-wheeled vehcle. The bracket 150 defines a "U'- 
shaped opening for receiving the horizontal leg 146 of 
the member 134. Apertures 152 in the bracket 150 are 
positioned to align with aperture 148, upon the bracket 
150 receiving the horizontal leg 146 of member 134. 
With the apertures aligned, the pin 154 may be inserted 
through the bracket 150 and leg 148, to secure the ve- 
hcle 16' to the carrier bracket 130. Accordingly the ve- 
hicle 1 6' may be carried by a vehkile 1 6, by simply con- 
necting the teg 1 44 to the standard tow-bar receptacle 
of a vehk:le 16, then placing the vehicle 16' on the hor- 
izontal leg 146 and inserting the pin 1 54 through the ap- 
ertures 148 and 152. Finally, the vehcle 16' may then 
be lifted by rotating the spool or reel 1 42 to take up some 
of the flexible band 1 40 and, thereby, draw the bracket 
1 34 in the vertcally upward directbn. The raising and 
lowering mechanism just described may be replaced by 
a variety of lifting mechanisms krK)wn in the art. For ex- 
ample the lifting mechanism provkJed may be a hydrau- 
lic, pneumatk:, rack and pinion, scissors and screw, or 
other mechanisms known in the art 
[0068] After relocating the veh k:les 1 6 and 1 6', the ve- 
hk:le 16'- may be detached from the bracket 130 by re- 
nrxwing pin 54 and lifting the vehcle 16' off of the hori- 
zontal leg 146. If needed, the member 134 may be k>w- 
ered by unwinding the spool or reel 142 to assist in re- 
moving the vehicle 16*. The lifting mechanism can ena- 
ble someone to transport a vehicle that would otherwise 
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be too heavy for an individual to lift onto a vehicle carrier 
without the lifting facility. 

[0069] In prefen^ed embodiments, many of the func- 
tions of the port facility computer system, the central fa- 
cility and the vehicle subsystem described above with 
respect to the flow charts of Figs. 2-4 can be implement- 
ed by programnnable computers and processors. Err>- 
bodiments of programmable computer or processor 
based facilities and vehicle subsystems are described 
below with reference to Figs. 6 - 10 as representative 
examples. However, It will be understood that the sys- 
tem and methods according to the present Invention 
may be implemented in various combinations of hard- 
ware and software configurations and are not limited to 
specific example configurations described herein. 

Port Facility: 

[0070] In preferred embodiments, the system 10 in 
Fig. 1 includes a plurality of port facility 14 located In 
geographically renrx>te locations relative to each other, 
for example, at locations convenient for a large number 
of potential users, such as near train or bus stations, 
campuses, office parks, shopping areas or the like. Two 
examples of vehk;le distribution port facility 14 are 
shown in Figs. 6 and 8, respectively. In the example em- 
bodiments of Figs. 6 and 8, the vehicle distribution port 
1 0 facility includes parking spaces 1 56 for parking a plu- 
rality of vehicles 16. In addition, the distributk>n port 10 
includes a computer subsystem 158 typically kx:ated at 
a kiosk 14 to facilitate user Interaction. Fig. 7 shows a 
generalized bkxk diagram representation of the com- 
puter subsystem 158, which Includes a computer 160, 
a display and user interface devce 162, and a commu- 
nlcatbns Interface 164 for communication with the cen- 
tral facility 12. The communications interface 164 may 
be, for example, a satellite, radio frequency RF or other 
wireless link. In whch case, the interface 1 64 wouW in- 
clude a transmitter/receiver In a preferred embodiment 
of the inventton, the Interface 164 between the central 
office facility and the subsystem 1 58 may comprise a 
hard wired connection, such as through conriputers 
linked to the Internet. Such a preferred embodiment Is 
illustrated In Fig. 14. In Fig 14 the user's Interface to the 
system Is a kiosk containing a computer, display screen, 
and one or more input devices such as a card reader 
and a keyboard and touch screen. A kiosk computer 250 
serves as a web client connected to the Internet. The 
system control computer 254 serves several functions, 
for example as the registratkxi web-server 256 process 
computer, It also provides a monitoring and control proc- 
ess 264 for the system. The registratkxi web-server 256 
serves the kbsk 250 computer web clients. The regisr 
tration web-sewer 256 also altows access to. the regis- 
tration web-server 256 by other computers connected ' 
to the Intemet. Having a web connection not only sinn- 
plifles the connectkxi of the kk>sk 250 computer(s) to 
the system by albwing the kiosk web clients 250 to be 



located anywhere there Is a ready connectkxi to the In- 
temet, it allows access to the vehicle sharing system 
from other Intemet connected computers. This is valu- 
able for users of the system because they nr^y access 
5 the system remotely, for example to make reservations 
for shared vehicles, to determine if vehicles are availa- 
ble at a port, to determine how kxig a wart there Is for a 
vehicle, to apply for membership in the vehk:le sharing 
system or for other reasons. 

10 [0071] The registratk)n web-server 256 also interfac- 
es with a database 258. The datat>ase 258 contains user 
data 266. in whk;h Is kept a record of user informatk)n 
and statistk:s. such as the time and date that the user 
used the system, the user ID. the destinatkyi of the past 
trip, vehcle information, port informatkxi. as well as the 
time and distance estinnates entered by the user for the ^ 
past trips. These statistics can be used to predict vehicle 
usage, for example rf a user makes a reservation for a 
shared vehicle. The database 256 may contain a user 

^ request database 268, in which user requests for vehi- 
cles arxj allocatkxi informatkxi of the vehicle may be 
kept, as well as a wart request data 262. The wait re- 
quest data 262 may contain information about vehicle 
requests that cannot be immediately filled, for lack of a 

25 vehk;le or In the case that the vehicle is, for instance an 
electrk:al vehicle, lack of a vehicle with sufficient battery 
charge. The wait request data 262 may contain such in- 
formation as the time and date that the user used the 
system, the user ID, the destinatkxi of the past trip re- 

30 quested as well as the time and distance estimates en- 
tered by the user for the trip requested. In one embodi- 
ment the wart request data may be on a separate com- 
puter and may be accessed by a user having the proper 
database permlsskxis 260. Safeguarding the wait re- 

35 quest database 262 is important because the monitoring 
and control process 264 within the system control com- 
puter 254 uses the wait request data 262 to allocate ve- 
hk:les to users who are waiting for vehcles. 
[0072] Fig. 1 5 Is a ftow diagram of the process when 

40 a user seeks a shared vehkile. As the user approaches 
the kbsk the system is idling, block 270. The user then 
swipes their Identiflcatkxi card at the kiosk card reader 
as in bkx:k 272. The card read by the kbsk card reader 
is the same card as used at the vehcle to gain entry, 

^ and Is also the same card used to gain access to the 
kbsk area. The kbsk computer then accesses the reg- 
istration web server in block 274. When communicatbn 
has been established between the registration web 
server 256 and the kiosk web client 250 computer, bbck 

50 276 Is executed. In bbck 276 user identifbation Infor- 
matbn, whbh has been obtained from the identificatbn 
card, abng with a kbsk ID bentrfying the transmitting 
kbsk, is sent to the regtstratbn web server Next In bbck ^ 
278 the registration web sen/er 256 compares the user 

55 ID received from the kiosk web client 250 computer to 
the active user list to see if the user is an authorized 
user. If the user ID Is invalid, bbck 282, the user Is told, 
in block 283, that their user I D is not valid and the system 
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returns to the idle state in bkxk 270. If the User ID is 
valid, block 280; then the registratkxi web server 256 
collects the user request information in block 284. The 
user request information consists of intomnation such as 
vehicle destination, estimated time of the trip, and esti- s 
mated distance of the trip. When the user information 
has been collected the registration web server 256 que- 
ries the shared system database, in bkx;k 286, in order 
to satisfy the request. In bkx;k 288 the registration web 
server 250 selects an available vehicle from the data- io 
base 258 to satisfy the user request. In bkx:k 290 the 
user is asked if they accept or decline the offered vehi- 
cle, If the user declines the vehicle, bkx;k 294. the reg- 
istratkxi web server 256 disconnects as seen in block 
296. If the user accepts the vehk:le,. in block 292, the ^s 
registratkxi web server 256 stores the trip request data 
in the shared vehicle database in bkx^k 298. Finally in 
block 300 a computer control process polls the vehk:le 
request database and processes the request. 
[0073] The comp uter subsystem 1 58 is preferably dis- 20 
posed in a well jit and highly visible locatk)n and, more 
preferably, is also housed within a building or enclosed 
structure 166 (as shown in Fig. 2), to which access is > . 
controlled for user security. Access may be controlled 
by an attendant stationed at the port facility 14 or by a 25 
standard lock and key system, wherein a key to the door 
168 is issued to each' user. However, in preferred em- 
bodiments, the door kx:k is controlled by a card key entry 
system and each user is issued a card key comprising 
a card on which magnetic, optical or other n^chine- 30 
readable data is recorded. In such systerhs, the en- 
closed structure 166 is provkled with an electrons door 
kx:k 170 (Fig. 7) and a card reader 172 disposed in a 
user accessible location outside of the structure 166, for 
example, adjacent the door 168. 3S 
[0074] To gain entry to the structure 1 66, a user must 
swipe or insert the user's card key past or in the card 
reader 172. to allow data from the card to be read and - 
communicated to the computer 1 60. The computer 1 60 
is programmed to process the user I D and, provided us- 40 
er ID is in the database of currently valid users, controls 
the electronic door lock 170 to unlock the door 168 and 
altow the user to enter the structure 166: For example, - 
the data may comprise a user klentification code or an r 
expiration date code and the connputer 1 60 may be pro- 45 
grcimmed to compare user identificatk>n code with a da- 
tabase of valkj user identificatkxi codes or compare the 
expiration date code with the current date. Thus, the 
computer 160 may be programmed to unlock the door 
1 72, only if the user identification code is valid or an ex- so 
piration date has not passed. 

[0075] Once the user has entered the structure 166, 
the user will have access to the port facility display and 
user interface device 162. The display and user inter- 
face device 162 may comprise any suitable display in- ss 
eluding, but not limited to, a cathode ray tube CFTT dis- 
play, liqukj crystal display LCD or the like, and any suit- 
able user interface, including, but not limited to, a touch- 



screen integrated with the display, a keytx^ard, a mouse, 
a joy stick or the like. For user convenience, a CRT dis- 
play with a touch -screen user interface is preferred. 
[0076] The display and user interface 1 62 is provided 
to display instructions, prompts and infomnation to the 
user and to altow the user to enter information, such as 
travel informatkxi and/or identificatkxi information, from 
the users ID card, for processing by the computer 160 
or communk^ation to the central facility 12. For added 
security, a second card reader (also represented by box 
172 in Fig. 7) may be disposed within the structure 166, 
adjacent the display and user interface 162. for the user 
to enter card key data to initiate or continue interactkxi 
with the display and user interface 162, As descrtoed 
above, travel information and/or identificatkxi informa- 
tion entered by a user at a port facility 14 is communi-" 
cated to the central facility 1 2 and is used by the central 
facility to select a vehrcle for the user to pick up at the 
port facility 14. 

[0077] In the Fig. 8 example, the vehicle parking spac- 
es 156 are located within an enclosed structure, such 
as a buikiing 174 having a gate or passage 176 through 
which vehicles nrtay enter and exit, for added vehk:le se^ . 
curity. In addition, the Fig. 8 example includes tracks 178 
for automated nnovement of vehcles between parking 
spaces 156 and the gate or passage 176. Thus, for ex- 
ample, a vehicle selected for a user 20 at the port facility 
nnay be automatcally nnoved from a parking space 1 56 
and delivered to the gate 176 for pick up by the user. 
Similarly, upon completkxi of a trip or upon delivery of 
a vehicle to the gate 176 of the port facility, the vehicle 
may be autbmatcally moved from the gate to a parking 
space 1 56. 

[0078] In preferred embodiments, the vehicle fleet in- 
cludes or is composed entirely of electric powered ve- 
hicles. Accordingly, each of the vehicle distributkxi port 
facility examples shown in Figs. 6 and 8 includes vehicle 
charging devices kx:ated adjacent at least some of the 
parking spaces. In the Fig. 8 example, the charging units 
may include automated connectors, for automatically 
connecting and disconnecting from vehicles in the park- 
ing spaces 156. 

Central facility 

[0079] A generalized block diagram representation of 
an example central facility 12 is shown in Fig. 9. The 
central facility 12 in Fig. 9 includes a computer 180 with 
an Internet connection 13, programmed for processing 
user travel and/or kjentifk:ation infomnatkxi received 
from vehicle distributkxi port facility and selecting vehi- 
cles for users, based on the received infomnatkxi. The 
central facility 1 2 also includes a transmitter/receiver 
unit 1 82 for connmunication with the vehicle subsystems 
18, for example using a satellite communcation link, an 
RF link or other suitable wireless link. As described 
above, the central facility 1 2 is also coupled for commu- 
nk:ation with the computer subsystems 158 at the vehi- 
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cle distribution port facility. That communication link may 
also be made through the transmitter/receiver unit 1B2 
or, altematrvely, through a separate communications 
link such as a hard wired link. 

[OOdO] As discussed above, the computer 1 80 is pref- 
erably programmed to conduct vehicle tracking rou- 
tines, for example, in accordance with standard vehicle 
tracking and communication software, including, but not 
limited to a Teletrac system (Teletrac is a tradenr^rk of 
Teletrac, Carlsbad California). Accordingly, the central 
offrce facility 12 also includes display devk:es 184, for 
providing a system administrator with visual information 
regarding the kx:ation and also regarding various nrKXi- 
itored operational corxJitions of vehrcles in the fleet, and 
an input devk:6 186, such as a keyboard, nrx>use, or the 
like, for alk>wing the system administrator to input in- 
structkxis and data. Preferably, the central office facility 
is located in a secure environment, such as a secure 
office building, where data relating to user identification 
codes and other sensitive or private information may be 
maintained in a secure manner. 

Vehk^le Subsystem : 

[0081] As described above, each vehicle 16 in the 
fleet is provided with a vehcle subsystem 18 for com- 
munk:ating with the central office facility 1 2 and for per- 
forming a variety of other functions, depending upon the 
embodiment of the invention. A generalized block dia- 
gram representation of a vehicle subsystem 1 8 is shown 
in Fig. 10. Each vehk^le subsystem 18 includes a pro- 
grammable processor or computer 1 88 for processing 
information and controlling the operatbn of other conrv 
ponents of the sut>system 18. Ttie vehicle subsystem 
18 also includes a transmitter/receiver unit 1 90 for wire- 
less communk:atkxi with the central facility, as dis- 
cussed above. The vehicle subsystem also includes a 
display and user interface unit -1 92. . . 
[0082] In embodiments in which the vehicles within 
the fleet are enclosed vehicles, such as those shown in 
Figs. 1 , 6 and 8, then the display and user interface unit 
1 92 is disposed within the enclosed interior of the vehi- 
cle, in a convenient kx:ation for access by a vehk:le user, . 
such as on. the center console, dashboard or overhead 
console. 

[0083] The vehcle subsystem for enclosed vehicles 
also includes a card reader 1 96 mounted for access by 
a user from outside of the vehcle. Thus, for example, 
Fig. 6 shows a card reader 196 nx^unted to the inside 
of the passenger window, behind the driver's side door. 
To gain access to the vehicle selected for a user, the 
user must swipe the card key past the card reader, to 
altow the data recorded on the card to be read. The data 
read by the card reader 1 96 is provided to the processor 
188 for comparison with data received from the central 
facility, through transmitter/receiver unit 190. The proc- 
essor 188 is programmed to control an electronic door 
lock 1 98 to unlock one or more vehcle doors and allow 



access to the vehcle inter k>r, upon a sufficient match 
between the compared data. 

[0084] Once the vehicle door is unkx:ked, the user 
may enter the vehicle and gain access to display and 
5 user interface 192. The processor 188 is programmed 
to operate with the display and user interface 192 to dis- 
play instructions to the user and to receive data input by 
the user, including a personal identification number PIN. 
The processor 188 is further programmed to enable or 
10 disable the operation of the vehcle by providing an en- 
able or disable signal 200 to an operatkxi-crilcal ele- 
ment, based on the valkJity of the PIN entered by the 
user. The enable or disable signal may be used to con- 
trol a suitable devce for enabling or disabling any oper- 
as ation-critcal element of the vehicle, including, but not 
limited to, the vehicle ignition system or fuel line (for in- 
temal combustion powered vehicles), the battery power, 
source, or the like. Devices whch respond to er«ble or 
disable signals for enabling or disabling ignition sys- 
20 tems, fuel lines, battery power sources or the like are 
welt known in the vehicle security fiekJ. In the case of an 
electric vehicle, for example, a disable signal wouki be 
activated by the vehicle being in a charging state. This 
would prevent the vehicle from being driven while it was 
2S connected to the charging facilities, thus eliminating 
damage that could be caused if the vehcle were acci- 
dentally driven while still connected to the charging fa- 
cilities. 

[0085] In further embodiments off the invention, the 

30 vehicle subsystem includes one or more parking state 
sensors 202, for sensing the parking state of the vehcle. 
As discussed above, the parking state of a vehicle may 
be sensed in various manners, including, but not limited 
to, sensing the setting of the transmission in the parking 

3S gear, the setting the parking brake, the lack of nDOve- 
ment for a predetermined period of time, the opening 
and/or ck>sing of a vehicle door or combinations off those 
events. In a preferred embodiment, a parking state is 
sensed by the combination of the vehicle being placed 

40 in a parking gear and the driver-skJe door being opened 
and vehicle speed being equal to zero. In such preferred 
embodiment, the parking state sensors 202 would, 
therefore, include a parking gear sensor for sensing the 
setting of the parking gear and a door sensor for sensing 

45 the opening and closing of the vehicle door. Other em- 
bodiments may contain various other methods for de- 
ckiing that a user trip is over For example the kxiation 
of the vehcle at the port may be taken into account in 
order to determine that vehcle is in the parking state 

so and the current trip has ended. There are several ways 
of determining that the vehicle is kx:ated at a port. The 
vehicle kx^tion system may place the vehicle at the 
port, the vehicle kJentity may be read at the entry gate . 
to the port for instance by tripping a switch, that may 

55- cause the vehcle kJentity to be read. The reading of a 
vehcle identity may also occur by sensors located at the 
vehcle parking spaces, or at the entrarx;e to the parking 
k>t. In addition placing a vehicle in park in a parking 



14 



27 



EP1067 481 A2 



28 



space and opening the door may signal the end of the 
trip, or a user may directly enter that the trip is over on 
the vehicle console. There is a great variety of flexibility 
in methods of deciding that a vehicle is in the parking 
state and the exact method chosen will depend on the 
implementation. 

[0086] In yet further embodiments of the invention in 
which vehicles in the fleet include electric powered ve- 
hicles, the vehicle subsystem for each electric powered 
vehicle includes a state of charge SOC monitor 204 for 
rrKxiitoring the available charge remaining in the vehi- 
cle. Data representing the SOC is provided to the proc- 
essor 188, for transmission to the central station 12 by 
the transmitter/receiver 190 for use vehicle allocation 
and monitoring functions described above. Data repre- . 
senting other parameters 207, such as vehicle speed, 
door open, vehicle charging, and so forth are also pro- 
vided to the processor 1 88, for transmission to the cen- 
tral station 1 2 by the transmitter/receiver 1 90. 
[0087] In yet further embodiments, the vehicle sub- 
system includes a vehicle location or tracking system. 
Such systems are known in the art. Vehk:le locatkxi may 
be tracked through a variety of methods, the vehicle it- 
self can employ triangulation using radio beacons or 
dead reckoning, the vehk;le may also be tracked by re- 
ceiving a signal from the vehicle and triangulating on 
that signal. In one further embodiment a GPS device 
206 provides kx^ation informatkxi to the processor 188, 
for transmisskxi to the central staton 1 2 and/or for pro- 
viding on-board tracking and route planning data The 
choice off tracking system, however is a matter of implo- 
mentatkxi convenience. 

[0088] The foregoing descriptkxi of the preferred em- 
bodiment of the invention has been presented for the 
purposes of illustratk>n and description. It is not intended 
to be exhaustive or to limit the invention to the precise 
form disck>sed. Many nxxlrficatkxns and variations are 
possible in light of the above teaching. For example,, 
while many of the data processing and decision making 
functkxis are described above as being performed by 
the central facility, other embodiments may include port 
facility computer substystems that are programmed to 
perform some of such functkxis. In yet further embodi- 
ments, the vehicle susbsystem may be programmed to 
perform some of such f ur^ctions. Therefore, it is intended 
that the scope of the invention be limited not by this de- 
tailed descriptbn, but rather by the claims appended 
hereto. 



Claims 

1. A vehicle sharing system for sharing one=or more.^ 
vehicles from a fleet of vehk:les among one or more 
users, the vehk:le alkx^tion system comprising: 

one or more ports at geographk:ally remote lo- 
catkxns relative to each other, each port having 
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a user interface terminal for receiving a request 
for a vehicle from the fleeti 
a computer system coupled for communication 
with the user interface terminal at each port and 
programmed for processing a user request re- 
ceived at a port and, in response thereto, for 
determining a group of vehicles from the fleet 
whk:h are available to the user at that port, sakJ 
group may include less than all of the vehicles 
in the fleet; and 

means for detecting a parking state of a vehicle 
from the fleet and, in response thereto, includ- 
ing the vehicle in the group of available vehicles 
of one of said ports. 

f' 

2. A system as recited in claim 1 , wherein sakJ means 
for detecting the parking state of a vehicle compris- 
es a sensor for sensing the setting of the vehk;le in 
a parking gear. 

3. A system as recited in claim 1 , wherein said means 
for detecting the parking state of the vehicle com- 
prises a sensor for sensing the opening and/or clos- 
ing of a door of the vehicle. 

4. A system as recited in claim 1 , wherein: 

sakl computer system includes means for de- 
tecting the kx:atk>n of each vehicle in the fleet; 
and 

sakJ means for detecting the parking state of 
each vehcle comprises means for determining 
whether the detected kx:ation of each vehicle 
is within a designated area. 

5. A system as recited in claim 1 , wherein: 

each port includes a parking facility in which., 
one or more vehicles may be parked at any giv- 
en time; 

sakJ computer system includes means for de- 
tecting the kx:ation of each vehicle in the fleet; 
and 

sakJ means for detecting the parking state of 
each vehk^le comprises means for determining 
whether the detected kx:ation of each vehicle 
is within the parking facility of one of said ports. 

6. A system as recited in claim 5. wherein a vehicle 
detected in a parking state of the parking facility of 
a port is included in the group of available vehicles 
of that port. 

7. A system as recited. in claim 1 , wherein: . 

sakJ computer system includes means for de- 
tecting the kx:atk)n of each vehicle in the fleet; 
and 
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said means for detecting the parking state of 
each vehicle comprises a sensor for sensing 
the setting of the associated vehicle in a park- 
ing gear and means for determining whether 
the detected kxation of each vehicle is within . 5 
a designated area and detects a parking state 
of a given vehicle upon the occurrence of both 
the vehicle being within the designated area 
and the vehicle being set in a parking gear. 

10 

8. A system as recited in claim 1, wherein: 

each port includes a parking facility in which 
one or more vehicles noay be parked at any. giv- 
en time; 

said computer system includes means for de- 
tecting the location of each vehicle in the fleet; 
and 

said means for detecting the parking state of 
each vehcle comprises a sensor for sensing 20 
the setting of the associated vehicle in a p>ark- 
ing gear and means for determining whether 
the detected kx:ation of each vehicle is within 
a parking facility of a port and detects a parking 
state of a given vehicle upon the occurrence of 2S 
both the vehk;le being within the parking facility 
of a port and the vehicle being set in a parking 
gear. 

9. A system as recited in claim 1, wherein: 30 

said computer system includes means for de- 
tecting the location of each vehicle in the fleet; 
and 

said means for detecting the parking state of a 3S 
given vehcle comprises a sensor for sensing 
the opening and/or closing of a door of the ve- 
hicle and means for determining whether the .^^ 
detected location of the vehicle is within a des- 
' ignated area and detects a parking state of the ^ 
given vehcle upon the occurrence of both the 
vehicle being within the designated area and 
the vehicle door opening and/or closing. 

10. A system as recited in claim 1, wherein: ^ 

each port includes a parking facility in which 
one or more vehcles nr^ay be parked at any giv- 
en time; 

said computer system includes means for de- 50 
tecting the location of each vehicle in the fleet; 
and 

said means for detecting the parking state of a ^ 

given vehicle comprises a sensor tor sensing v. 
the opening and/or cbsing of a door of the ve- ss 
hide and mear^s for determining whether the 
detected kx:atkxi of the vehcle is within a park- 
ing facility of a port and detects a parking state 



of the given vehcle upon the occurrence of both 
the vehicle being within the parking facilrty of a 
port and the vehicle door opening and/or clos- 
ing. 

11. A system as recited in claim 1, wherein said com- 
puter system is further programmed to select and 
allocate one of the vehcles from the group of avail- 
able vehcles, in response to a request for a vehicle. 

12. A system as recited in claim 11 , wherein said com- 
puter system is further programmed to remove a ve- 
hcle from the group of available vehicles at a port, 
upon a! kxation of the vehcle, in response to a re- 
quest. 

1 3. A system as recited in claim 12, wherein saki com- 
puter system is further programmed to return an al- 
kx:ated vehicle to the group of available vehicles at 
a port upon return of the vehicle to the port and plac- 
ing of the vehcle in a parking state. 

14. A system as recited in claim 12, wherein said com- 
puter system is further programmed to return an al- 
kx^ted vehicle to the group of available vehicles at 
a port, upon failure of the user to confirm receipt of 
the vehcle within a preset time from the allocatk>n 
of the vehicle. 

15. A method for sharing one or nrxjre vehicles from a 
fleet of vehcles anrnxig one or more users, the 
method comprising: 

providing a user interface at one or more ports 
at geographcally remote kx:atk)ns relative to 
each other, 

receiving a request for a vehicle from the fleet 
on a user interface terminal at one of said ports; 
determining, in response to a user request, a 
group of vehcles from the fleet which are avail- 
able to the user at that port, said group may in- 
clude less than all of the vehcles in the fleet; 
and 

detecting a parking state of a vehicte f rom the 
fleet and, in response thereto, including the ve- 
hcle in the group of available vehicles of one 
of sakj ports. 

16. A method as recited in claim 15, wherein said step 
of detecting the parking state of a vehicle comprises 
sensing the setting of the vehicle in a parking gear. 

17. A method.as recited, in claim ;1 5, wherein said step. 
of detecting the parking state of the vehcle com-- 
prises sensing the opening and/or ck>sing of a door 
of the vehicle. 

18. A method as recited in claim 15, further comprising 
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the step of detecting the location of each vehicle in 
the fleet, and wherein said step o1 detecting the 
parking state of each vehicle comprises determin- 
ing whether the detected location of each vehicle is 
within a designated area. . 5 

19. A method as recited in claim 15, further comprising 
the step of detecting the location of each vehicle in 
the fleet, and wherein said step of detecting the 
parking state of each vehicle comprises determin- io 
ing whether the detected kx:ation of each vehicle is 
within a parking facility of one of sakj ports. 

20. A method as recited in claim 19, wherein a vehk:le 
detected in a parking state of the parking facility of . 
a port Is included in the group of available vehk:les 
of that port. 

21. A method as recited in claim 15, further including 

the step of detecting the location of each vehicle in 20 
the fleet, and wherein the step of detecting the park- 
ing state of each vehcle comprises sensing the set- 
ting of the associated vehicle in a parking gear and 
determining whether the detected kx^ation of each 
vehicle is within a designated area, wherein a park- 2S 
ing state of a given vehcle is detected upon the oc- 
currence of both the vehcle being within the desig- 
nated area and the vehicle being set in a parking 
gear. 



22. A method as recited in claim 15, further comprising 
the step of selecting one of the vehcles from the 
group of available vehicles, in response to a request 
for a vehicle. 

23. A method as recited in claim 22, further comprising 
the step of renrKSving a vehicle from the group of 
available vehcles at a port^ upon allocatk)n of the 
vehicle, in response to a request. 
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24. A method as recited in claim 23, further comprising 
the step of returning an allocated vehicle to the 
group of available vehicles at a port upon return of 
the vehcle. to the port and placing of the vehicle in 

a parking state. ^ 

25. A system as recited in claim 23, further comprising 
the step of retuming an allocated vehicle to the 
group of available vehicles at a port, upon failure of 

the user to confirm receipt of the vehcle within a 50 
preset time from the allocation of the vehicle. 
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